fix some 'imports' errors #53
Conversation
hallyn
requested review from
joylatten,
mikemccracken,
raharper,
rchamarthy,
rchincha and
smoser
The stackerfiles were using import: but looking for files under /stacker/imports. You have to use imports: for that. Also, imports: with an import of 'dracut/' will take all the contents of dracut/ and import them, rather than recursively import the dracut directory. But we were expecting the dracut directory. So drop the trailing slash. Signed-off-by: Serge Hallyn <serge@hallyn.com>
hallyn
force-pushed
the
2024-12-27/importsfixes
branch
from
8cf4adc to
345dbc2
Compare
So don't try building snakeoil keyset right now, and don't try publishing results. Signed-off-by: Serge Hallyn <serge@hallyn.com>
raharper
left a comment
raharper
left a comment
There was a problem hiding this comment.
LGTM. Without snakeoil and trust, is the published bootkit layer still functional? IIUC, users would still need to get trust themselves and generate their own keys (which they should do anyhow), right?
Well there are no published bootkit layers right now :) But yes, this just got me far enough that I could do a 'make' and get an interesting initrd, but things are not actually usable. I have a patch I haven't posted for 'mos' to accept a BOOTKIT_URL to let me pass an oci: url for the bootkit layer that 'trust keyset add' fetches. So then I can build bootkit and create keysets using that, and then I can build a bootable image from that. But it's not entirely useful. I've been trying to think of the best path forward. Clearly for apic the whole pcr signdata route is still necessary. Me right now I just want to go more of a hybrid route between this and the systemd ukify route. I want to use a remote soci url for the rootfs, but using the systemd way of using pcr7 and pcr11 (which doesn't require any signdata). I could just go whole-hog into using mkosi to generate images, and that would work. But I'd prefer for initrd to use atomfs from a zot server to mount the rfs. I'm not sure where to best draw the lines there. I don't know how much this interests you (or @mikemccracken ) - if it does, I'd love to chat on Monday about the details. |
|
BTW regarding published images, and ignoring my own desired use case, yes even 6 months ago I was convinced we wanted to stop pushing and pulling anything to/from zothub.io, and just have everything build locally in sequence using each other's artifacts. The "fleet of securely booted IOT devices running docker://myzot/myapp:1.0.0 using three simple steps" required some use of zothub.io for bootstrapping, but I don't think we're pushing for that any more. (or are we?) |
OK
Right
I'm definitely interested. I'd like to dig deeper into the systemd/mkosi path
With that in hand, I'd like to see about patching and possibly upstreaming I'm hoping that we could also extend distro standard initrd to do atomfs |
I do think that model is useful; but I think we need to sort out things on the |
The stackerfiles were using import: but looking for files
under /stacker/imports. You have to use imports: for that.
Also, imports: with an import of 'dracut/' will take all the contents of dracut/ and import them, rather than recursively import the dracut directory. But we were expecting the dracut directory. So drop the trailing slash.